ThingsBoard:实现MQTT连接、报警和数据转换规则的强大引擎 |
您所在的位置:网站首页 › thingsboard 源码 队列 › ThingsBoard:实现MQTT连接、报警和数据转换规则的强大引擎 |
MQTT 客户端接入
之前都是采用HTTP RESTFUL API方式去接入ThingsBoard。ThingsBoard能够兼容多种协议,今天就来尝试下使用MQTT 客户端接入ThingsBoard。客户端采用MQTTX工具。 hello world 新增设备 复制ACCESS_TOKEN,输入到MQTTX客户端的usernameThingsBoard 服务器已经接收到MQTT客户端发送的数据。 设备配置设置 根规则链默认情况下,根规则处理所有入站消息跟入站事件信息。当系统接入设备越来越多时,根规则链也就越来越复杂。因此平台用户可以根据设备类型创建特殊的规则链,处理各种信息,用来降低根规则链的复杂性。 为了避免上述业务痛点,从ThingsBoard3.2,针对特殊设备,你可以自定义根规则链。新的根规则链接收、处理所有的传感数据,如设备活跃状态、设备生命周期管理(创建、更新、删除)事件。 默认情况下,Main队列用于存储所有入站消息、入站事件。传输层提交信息至该队列,规则引擎拉取消息进行事件处理。然后复杂场景下,为了隔离数据处理,你可能需要单独的消息队列进行数据存储。或者针对不同类型的设备使用不同的消息队列。 ThingsBoard3.2开始,系统支持两种传输类型: 默认 、MQTT 默认传输类型默认传输类型旨在兼容早起版本,使用默认传输类型,可以继续使用平台默认的MQTT、HTTP、Coap和LwM2M API来链接设备。默认传输类型没有特定的配置设置 MQTT传输类型MQTT传输类型启用高级MQTTT传送设置。不同于默认的传输类型,它可以自定义MQTT协议topic 过滤、属性更新等特性。创建一个MQTT传输类型的设备配置文件,如下图: 设置MQTT传输类型 指定topic名称 需要注意的是 这里有两个TOPIC; 应用分别如下 遥测数据TOPIC筛选器 – 对应设备检测实时数据的topic Attributes topic filter – 设备属性(如版本号)上报的topic两种topic都支持模糊匹配,+号表示匹配一级,#匹配多级 MQTT配置案例 发送检测数据截图参考下面 规则转换引擎 -> 数据展示部分 发送属性数据特别注意 要想设备规则生效,需要注意以下两点(本人采坑折腾了个把小时) 设置MQTT设备配置为默认配置 新增的设备关联MQTT设备配置 假设设备正在采集并上报温度数据(华氏度),但是ThingsBoard平台需要展示摄氏度,因此底层需要将他们进行转换,此时规则引擎派上用场,数据转换的公式如下: [°C] = ([°F] - 32) × 5/9. 增加转换规则节点点击 ”规则链库“ -> 选中根节点 -> 打开规则链,如下图 转换脚本如下 function precisionRound(number, precision) { var factor = Math.pow(10, precision); return Math.round(number * factor) / factor; } if (typeof msg.temperature !== 'undefined'){ msg.temperature = precisionRound((msg.temperature -32) * 5 / 9, 2); } return {msg: msg, metadata: metadata, msgType: msgType}; 验证规则点击上图 “Test transformer function” 验证脚本是否正常 转换规则节点在规则链中的位置如下 如上图,可以在设备最新的数据检查中观察到温度数据已经进行转换。 设备状态监控物联网开发中,常用的业务是监控设备的状态,出现异常(如掉线)情况则触发报警通知,进行人工干预进行处理。ThingsBoard设备状态检测服务监控设备连接状态,并把连接事件推送给规则引擎。ThingsBoard支持一下四种事件类型: Event Type Description Connect 设备连接到ThingsBoard时触发 Disconnect 设备断开链接时触发 Activity 设备发送数据、属性更新、接口调用时触发 Inactivity 当设备在一定时间段内不活动时触发下面详细地讲解一下Inactivity事件是如何操作 如何通过规则引擎创建Inactivity报警 配置Inactivity事件超时参数 新增设备新增设备 ,并设置Inactivity事件超时参数 新增设备 设备名称: Inactivity-timeout-device 选中设备 选择属性 -> 服务端属性 设置inactivityTimeout属性 6000毫秒,即一分钟 打开规则链,如下图 光秃秃的啥都没有,后面一个个规则节点添加 这个规则节点将会根据消息类型路由入站信息,比如 POST_TELEMETRY_REQUEST; POST_ATTRIBUTES_REQUEST; ACTIVITY_EVENT; INACTIVITY_EVENT.将节点关联到Message Type Switch节点,关联类型为 Post telemetry。该节点会保存设备发送的消息至数据中 节点关联 Message Type Switch 节点,关联类型为Post attributes,该节点会存储设备上报的相关属性信息。 节点关联 Message Type Switch 节点,关联类型为Inactivity Event.该节点将根据报警配置产生报警信息。如果存在未清除的报警,则更新报警,否则将创建新的报警。 节点关联 Message Type Switch 节点,关联类型为Activity Event.该节点会存储设备上报的相关属性信息。该节点将根据报警配置清除报警信息(如果存在)。根规则链最终效果图如下 设备配置关联规则链 说明,如上图设备最后一次活动时间是 22:15:12 秒,理论上一分钟之后设备变成 Inactivity 状态,什么为什么把报警时间 是 22:16:40,比预期的时间晚了28秒。 回答这个问题,我们需要了解 ThingsBoard 内部检测原理,即ThingsBoard是通过什么样的机制检测设备状态,摘录自官网的一段话: Device State service uses a global configuration parameter to detect inactivity events. This parameter is defined in thingsboard.yml (state.defaultStateCheckIntervalInSec) and by default it is set to 60 seconds (1 minute). 使用全局的配置检测inactivity 事件,可以修改thingsboard.yml文件中的state.defaultStateCheckIntervalInSec参数,默认60秒。 我试过好几次,添加多个设备观察到本机的inactivity报警时间基本维持在40-41秒这两个值的区间。个人感觉跟ThingsBoard服务的启动时间有关系。为了达到1分钟之后报警,可以尝试去修改下默认参数,测试下。我就不折腾了 您可能感兴趣的内容: python项目-飞机大战 Frida Hook 常用函数、java 层 hook、so 层 hook、RPC、群控 tkinter模块高级操作(一)—— 透明按钮、透明文本框、自定义按钮及自定义文本框 基于ROS的PX4+Gazebo仿真——PX4一键起飞及飞行控制 【python教程】– 入门 | 小甲鱼《零基础入门学Python》教程笔记(知识点详细、源码可复制)全 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |